Date: Thu, 19 Oct 2006 13:02:08 +0900 From: SUZUKI Shinsuke <suz@freebsd.org> To: chenxiaochen@emcite.com,gnn@freebsd.org Cc: freebsd-net@freebsd.org, liangbing@emcite.com Subject: Re: Problems under test of IPv6 Ready Logo Program Phase-2 Message-ID: <x764ehc5rz.wl%suz@alaxala.net> In-Reply-To: <m2slhl8ce7.wl%gnn@neville-neil.com> References: <200610181908570311458@emcite.com> <m2slhl8ce7.wl%gnn@neville-neil.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, Here's my comment based on my IPv6Ready Logo(Ph.2) work in KAME Project. >>>>> On Wed, 18 Oct 2006 15:52:48 -0700 >>>>> gnn@freebsd.org said: > Though some of us are using TAHI I do not believe the project itself > is going for the Logo Program. TAHI Project is one of the major member of the Logo program. (TAHI provides a automatic testing tool for the Logo program) Please see the following pages for further detail. http://www.ipv6ready.org/about_logo_program.html > > 1. Section 5: RFC 2463 - ICMPv6 > > "case 11 Part B: Multicast Destination" --- fail > > After TN send Echo Request to global multicast > > address(ff1e::1:2), the following words appear on NUT's > > screen-----rl1:discard oversize frame (ether type 86dd flags 3 > > len 1514 > max 1294 ) > > However, "case 10 Part A: Unicast Destination" passes. Judging from the above message and the source code, it seems like you've configured rl1's MTU as 1280 and send a 1500-byte packet on rl1. You should send the packet on rl0 (where its MTU is 1500). > > 2. Section 2: RFC 2461 - Neighbor Discovery for IPv6 > > "127 Part C: Sending Unsolicited RA (Min Values)" --- fail > > After NUT excutes rtadvd, TN says "Could't observe RA". #This is a test item to see the interval of the RA messages. So NUT #must run rtadvd (by hand or automatic operation by TAHI-tool) This message appears even when TN receives an RA (with an unexpected parameter). You should carefully check the log of the self-test tool to see what is an unexpected parameter. > > 3. Section 3: RFC 2462 - IPv6 Stateless Address Autoconfiguration > > All cases fail > > Reason----TN can't observe DAD process. > > I can't capture DAD packages by Ethereal in the network start process. (snip) > I have not heard of this and don't have that hardware so can't check it. I've encountered the same phenomenon sometimes. It seems like there's a short amount of time where IFF_UP bit changes from off to on, but the hardware is not ready to send a packet. (appears like an ethernet auto-negotiation has not been completely finished) Since DAD process is kicked just after link-local address configuration (normally when IFF_UP bit changes from OFF to ON), it is inevitable in such drivers. My recommendation is either of the following two. (only to pass the IPv6-Ready Logo testing) - set net.inet6.ip6.auto_linklocal to 0 - manually configures a link-local address after the auto-negotiation has been completely finished or - disable auto-negotiation or (to make all the freebsd users happy:-)) - hack the device driver to make IFF_UP on after the hardware is ready to send a packet Thanks, ---- SUZUKI, Shinsuke @ KAME Project
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?x764ehc5rz.wl%suz>